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Hoa to use DECNET DEC/Xll # odules 



iiO INTRODUCTION 

Every installation has one particular configuration of 
communications equipment and it would be nice if this product, 
DECNET DEC/X11 (D,D.), would match your installation perfectly 
with no modifications. However, since we are required to test 
many installations, you, the user, must custom tailor your 
D.D. exerciser to match your equipment. The number of 
variations possible with communications equipment is almost 
endless, and if you match 99% of the D»0* exerciser 
characteristics to your installation characteristics it is 
still not good enough, You must specify a D.D, exerciser 
that EXACTLY catches your equipment to avoid wasted hours of 
chasing "non-bugs", if you successfully build a D.D. 
exerciser you will have a very useful product. The D.D. 
exerciser car now do complete DEC/Xll system exercising while 
simultaneously exercising all your communications lines, using 
the exact same data paths and data links as the operating 
system normally run on your system. Every attempt has been 
made such that a user of D.D. can build and use an exerciser 
without requiring any documentation on hand, if, and this is a 
big if, he has a complete knowledge cf normal DEC/Xll building 
and running and he has read and understood this entire 
document. If you come across any instance where this is not 
true, please notify the DEC/Xll group In Maynard and the 
situation will be remedied. If you are completely unfamiliar 
with communication equipment, I suggest you get and read 
Introduction to Data Communication by Murphy and Kallis, and 
introduction to Hinicoirpu ter Networks by Stelmach, These are 
both small, easy reading paperbacks available from DEC. 

240 BUILDING A DECNET DEC/Xll EXERCISER 

************* ************** *************** 

You must be familiar with building a 
normal DEC/Xll exerciser* If you are not, 
please read, and then build and run some 
exercisers before continuing on with this 
section, 

****************************************** 

2.1 Modules Required 

There is a one-to-one correspondence between communications 
options which D.D, supports and CD. modules used to test 
tnese options. The D,D. modules nave a 4 letter name, 
NXG7.0BJ, where, NX is formed by replacing the D in a 
communications option name with an N, the is an option 
selection, and ? is the revision letter. (Throughout the 
rest of this document, a ? as the last charcater in a module 
name indicates the latest revision available,) For example, 
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the first 0. D. module written to test the 0L11-E option was 
called NLA A .OBJ. NL coies from changing DL to NL, the next A 
indicates which option type. (In the case of the DL, there 
are no others to confuse it with, but if a DLX11 module was 
ever manufactured, the module name for it would be NLBA.OBJ.) 
D.D. modules will, in general, support 16 lines per module. 
In the case of a single line device, such as the DUll, the 
NUA? module will handle up to 16 devices, in the case of 
multiplexor devices with 16 lines, only one device is 
supported per module. So if your system had 2 OHll's, you 
would have to configure 2 NBA? modules to drive all 32 lines. 
The exception to this rule will be the DZ module, NZA?, which 
only supports 1 device, eight lines. 

In addition to these device dependent modules, 2 extra utility 
modules must be configured to support any D.D. module. The 
first, Nl A7.0PJ, contains a message buffer used by all D.D. 
modules to transmit from. In addition, it contains many 
common subroutines which all D.D. modules use. This helps 
keep down the size of the D.D. modules. The second module, 
N2A7.CBJ, serves as a "synchronization" module, it gives all 
systems being exercised in the network a "pause" point, to 
enable all data links to be established. It also services any 
DNll's (auto-call devices) which a system might have. Lastly, 
a clock module must be configured, either KWA? or KWB?. 
These modules keep a system time for the DEC/X11 monitor. 
D.D, modules? h?ve many time out loops which are implemented 
by using this system clock. 

****************************************** 

In the future, a fake clock module, KaX?, 
will be written, this will be a background 
module which will up the system time, but 
in an extremely inaccurate manner. This 
will allow D.D. modules to be run on 
systems without a Kfclll-L or KW11-P clock. 
The time-out loops in the D.D. modules 
will likely become undesirably long, but 
this cannot be avoided. 

****************************************** 

For any given communication option, there will likely be two 
DSC/X11 modules, the normal one whose first letter of the name 
is a D (e.g., DL A? ) , and a DECNET CEC/Xll one, whose name 
starts with an N (e.g., NLA?). They are mutally exclusive. 
You should not configure two modules to test the same device. 
It is ok to, for example, configure DLAF to test one DL11-E 
and NLA? to test a second, but extreme care must be taken not 
to have 2 modules trying to test the same device. In the case 
of a multiplexor, such as the DJil, it is impossible to test, 
say, 4 lines in DEC NET DSC/X11 mode, and the 12 in normal 
DEC/Xll maintenance moce, at the same time. 
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2*2 The order of Modules 

In normal DEC/X11, there are no ordering constraints with 
regards to modules* They can be configured in any order you 
desire, with the possible exception of the clock modules. 
They should be configured directly after the monitor to insure 
the run time is not made inaccurate by any delay in the clock 
module being initiated, but this is not a requirement. When 
building a D.D* exerciser/ there are some very definate rules 
about ordering of modules. In particular, directly after the 
monitor, the N1A? module must be configured. Following it, 
in any order, ALL CD. modules must come, followed by the 
N2A? module. Next the clock module should come, followed by 
all the rest of the normal DEC/ XII modules in any order. This 
results in a exerciser that looks like: 

Monitor (normal DEC/X11 or 11/70 monitor) 
N1A? 

N? A? ! Any and all 
!D.D. type 
•modules 

N?A? 

N2A? 

KW?? Clock module 

XXXX !Any normal 

IDEC/Xll modules 

lin any order. 

XXXX 

This results in a "sandwich" of all D-D. modules with N1A? 
on top and N2A? on bottom! If these ordering rules are 
violated many different errors will result. If no clock 
module is included in the configuration, the exerciser will 
halt itself after typing a message, and will therefore be 
useless. The library file which contains all these CD. type 
modules has N1A? as the first module and N2A? as the last, 
so when using the ^ AKE command tc build an exerciser, this 
library should be specified after the monitor library and this 
will guarantee the correct order of modules. 

242 Module Parameters at Configuration Time 

$hen building a D.D. exerciser, DVA, VCT, BR1, BR2, DVC, and 
SRI can all be specified, exactly as is done in normal 
DEC/X11. DVA arid VCT should be the lowest address of the 
devices which any one module is intended to exercise*. BR1 and 
BR2 should be the highest of the devices receiver and 
transmitter bus request levels, respectively. DVC, at 
configuration time, is the number cf lines to be tested for 
that module. It is converted into a bit map in the resulting 
exerciser. SP1 should be set to a bit map, with bits=l for 
lines which should act as Master and for lines to act as 
Slaves, faster and Slave are defined in section 3. For 
example, if your system had 3 DU11 "s, yi th the following 
hardware parameters: 
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#1 DU11, at 175610 and vector at 400, receiver priority of 5 
and transmitter priority of 5, to be tested as a Master. 

#2 DU11, at 175620 and vector at 410, receiver priority of 5 
and transmitter priority of 5, to be tested as a Slave. 

#3 DUll, at 175630 and vector at 42C, receiver priority of 6, 
and transmitter priority of 5, to be tested as a Haster. 

You would configure the NUA? module, specifying DVA of 175610 
(the lowest of the 3), vector of 400 (the lowest of the 3). 
Bfll as 6 (the highest of the receivers) and 8R2 of 5 (the 
highest of the transmitters). DVC should be 3, meaning 3 
lines to be tested, however, if you examined location 14 in 
the header of NUA? in the resulting run time exerciser, you 
would find it was a 7, being 3 binary bits on, one for each 
line. SP1 should be a 5, being bit on, bit 1 off, and bit 2 
on, corresponding to the faster, Slave, Master testing modes 
which we wanted for line 0, 1 and 2. All of these parameters 
may be altered when running the exerciser* but remember the 
different method of representing DVC at configuration and run 
time. If the bit for a line is not set in DVC, this means the 
line will not be accessed at all, so the corresponding bit in 
SPl will have no meaning. 

None of these 6 parameters have any meaning for the N 1 A? 
module. For the N2A? module SRI should be zero unless you 
have 1 or more DN-ll's, in which bit should be set to a one. 

NGTE , this DN-11 option is unsupported so far because no 
hardware has been available to test it on. 

Set DVA for the N2A? module to the lowest device address of 
your DN-ll*s, VCT to the lowest vector of your DN-ll's, and 
BR1 to the interupt level. 

3*0 TESTING THE NETWORK NCCE 

After successfully building a D*D. run time exerciser, you 
are now ready to test your Network Node. 

3il which Tests to Run 

To assure correct identification of any problems, I would 
strongly recommend running stand-alone diagnostics on all 
devices first. If they all pass, you should run a normal 
DEC/X11 exerciser which exercises all devices, including the 
communication equipment. If this passes, then continue on and 
attempt to run DEC NET DEC/X11. Gf course there are many 
exceptional cases where this "bottom up" testing is impossible 
for time or other reasons. If you are positive a problem is 
in some specific communication device, then you might skip 
running diagnostic on all the other equipment and just run the 
stand-alone on that one communications device, if that passes 
you should then run regular DEC/X11 to all the devices, and 
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only then, run DECNET BEC/X11. If you do not think there are 
any problems with the system and only want to run a confidence 
test on the system or the quality of the communication links, 
you might go directly with DECNET DEC/X11, but if problems 
develop you should fail back to the simplest test which will 
fail/ either normal DEC/X11, or preferably, a stand-alone 
diagnostic. 

Running DECNET DEC/X11, Overview 



NOTE 

Reference is made to "multi-drop" testing and DM11 
auto-call units throughout this document and 
individual DECNET DEC/X11 module documents. Both 
these features are "designed in" but completely 
untested end will not be supported until some future 
unknown date. 



First boot the system, load and start the D.D. exerciser. It 
will look exactly like normal DEC/X11. You can use the HAP 
command to find out which and where the modules are. You can 
use the wqq coirmand to modify any Parameters or options, you 
can use the SFL and DSS commands to turn on and off modules. 

************************** * *************** 

WARNING 

The N 1 A A , N2A&, clock, and at least 1 
DsCNET DEC/X11 module must be left 
selected if any D.D. module is selected. 
You should not select N1AA without N2AA 
and at least 1 DSCNET module, etc. It is 
perfectly all right to deselect NlA?, M2A? 
and ALL D.D, type modules, and just run 
noriral modules, or deselect all normal 
modules and run just NlA?, N2A?, clock, 
and one or more D.D. modules, but any 
D.D. type module which is selected 
positively requires NlA?, N2A?, and the 
clock, to be selected, and they in turn, 
if selected, expect at least 1 D.D. 
module to be running. 

****************************************** 

The first time an exerciser is run, it will type out a table 
of error codes and their meanings for D.D. modules. This is 
further explained in the section on errors. (Leaving bit up 
in the switch register will inhibit this typing) 

First deselect NlA?, N 2 A?, and ALL D.D. modules and select 
all other modules, Run this for 10 minutes, or long enough for 
every module to make 2 passes, whichever is longer. Next/ 
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deselect all modules and select N1A?, N2A?, and all D.D. type 
modules, and the clock module. Run this* It yill not begin 
running all modules yet. It will ask you to select which 
message you want to use for Network testing. ¥ou have a 
choice of all zeros, all ones, alternating 1 and O's, a digit 
count pattern, or a precanned ASCII message, (called the 
standard message). These are all 501 character long messages, 
plus 11 characters which get added as a header and CRC's. You 
can also type in any message you choose which will also have 
1! characters added to it. Lastly, you can specify to use the 
message which was previously specified. (This is for 
re-starting the exercising when you have not re-booted.) This 
message which you specify is the only message which the D.D. 
modules will use. It is very important that any node which 
you are connected to, must use the EXACT same message, 
otherwise, you will have false errors reported. At this 
point, the N1A? module will do an end of pass call and, 
because it is a special NBKMOD, it will not run any more 
passes* More about this will be mentioned later in this 
document. 

Next, each one mf the DECNET DEC/X11 modules will be started, 
in turn. When started, they will check to see which lines you 
have selected to test (by the DVC command when configuring or 
by MCD *ing location 14 in the module's header). For each line 
selected, the module will ask if the line is to be tested in 
full duplex or not (not means half duplex). Remember that 
although most of Digital's communication equipment is capable 
of running full duplex, many modems are not. If the modem for 
that line is not, you aust run half duplex. Next it will ask 
for each line selected, if that line is to be tested in 
tful ti-drop mode or not (not means point-to-point). If the 
answer is yes, it will ask for the station address of that 
multi-drop line, or if that line has been selected as a Master 
in SRI, it will ask for station addresses to be tested 
repeatedly until either 15 addresses have been entered or a 
(minus sign) is typed. By far and away the most common lines 
are half-duplex and point-to-point. When the module has this 
information, it then sets the Data Terminal Ready line to the 
modem. A modem can not make and maintain a connection to 
another modem unless both modems have their Data Terminal 
Ready lines selected. The module will then EXIT to the 
monitor and wait for a Global location called WAIT in the N2 A A 
module to be cleared, indicating that all phone connections 
have been made. This sequence is repeated by each D.D. 
module selected until they have all been started. By 
modifying location 164 in module NlA? to a 000001, the 
questions about lines will not be asked each time the 
exerciser is started. If the line parameters need to be 
changed, this location must be cleared. While answering line 
questions about a particular module, the ,f @" character will 
skip the rest of the questions for that module and leave the 
remaining parameters unchanged. 

Next the N 2 A A module is started. It, if SRI has bit set/ 
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will ask for a phone number to supply to a DN11 auto call 
option. It will then attempt to make the phone call* if it 
fails, it will type out? 
ON ERROR X 
where X is^ 

when present next digit bit is not set 

1 when power in the auto-call unit failed or abandoned call 
and retry bit was set 

2 when the software ti$ed out while waiting for a call to 
complete 

2 iihen power is not on in auto-call unit 

After it makes that call it returns for another number until 
only a carriage return is typed/ indicating no more Doll's. 
Next, or first if SRI * es indicating no DNl ! 's, the module 
will type a message requesting the operator to dial all manual 
connections, and type a carriage return when complete. 

It is important that all nodes in the Network being tested 
have this message (or the 'P#* message if DHll's are selected) 
typed out before any phone connections are attempted. This is 
the only way you can guarantee that all modems have had their 
Data Terminal Ready line set. When ALL nodes have had the 
message for manual phone connections or the ONll prompt for 
the first ohone number (P#) typed, the operators at each node 
should make the required automatic and manual phone 
connections, typing the carriage return when done. This last 
carriage return is really the start of DSCNET DSC/X11 testing. 
Immediately after it is typed, the global location 8AIT is 
cleared, allowing all D.D. modules to begin attempting to 
transmit and receive the message specified* Also, all normal 
DEC/X11 modules (if selected) will be started. The U2h? 
module will then drop itself because it is no longer needed. 

If this grouD of modules runs successfully for at least 8 
passes each, you should then select all modules and attempt to 
run again. Location 364 in module NlA? can be MOD'ed to a 
000001 if ycu want to skip the question and answer dialogue 
regarding multi-drop or not and full-duplex or not. If you 
later want to change these parameters, this location should be 
set back to zero before running^ Also, when answering these 
questions for multi-drop and half-duplex, a "(&" and carriage 
return indicates you do not wish to modify any lore of these 
types of parameters for this module. 

3*3 Legal Network Node Configurations and Modes 

Any one line of a communications option may be connected to 
many different "ends" and this line may be run in many 
different, modes. Furthermore, any one node running an 

; ^ « = — « - - - V- l _r _ _ j _ u _ _ u „ 

CACltiaci lci< neve «cuy oUv>u liiicj cctii i iii^ i~> e 

running in different modes and connected to different type 
"ends". As you can see, this can become quite complicated. 
To make it any simpler envolves taking away features and 
options, which is not desirable. I strongly recommend that a 
Network map be drawn showing each Node, what it is connected 
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to each other node by (device type, address, vector, modem 
type, data link type, baud rate, and half or full duplex), and 
what software the Nodes will be running* If this is done 
carefully, many problems, such as connecting asynchronous 
devices to synchronous modems or connecting devices with 
unlike bawd rates, can be avoided. 

3^3.1 What Caa a Line be Connected To? 

Any 0H€ line from a communication device can be connected to: 

a. Any staple "loop back" device which turns the transmit 
si§»ais around to the receive side* Synchronous devices 
do mot have a clock to strobe the data bits out with, so 
sacfe a loop back device must have a clocking mechainism 
f@r synchronous devices, If this loopback device does 
contain a buffer to allow an entire message to be captured 
and TffEN echoed back to the communications device, the 
coamnnication device can be run in half or full duplex. 
If the loopback device does not buffer the message, but 
rather, just ties the transmitted data line directly to 
the receive data line, then the communication device must 
be run in full duplex, Waster mode. Below is a list of 
known loopback devices which will work: 

Hone Yet 

This list will be added to as new loopback devices are 
tested and confirmed. 

b. Another line on the same systeir subject to 1 restriction. 
If the 7 lines involved are being controlled by seperate 
D.D. modules, there is no problem, but if they are both 
being run by one D.D. module, then you must insure that 
both lines are being being run by the module at the same 
time. Later sections of this document will explain more 
about what this means and how to properly connect and 
select the software options to assure this. Although any 
one ©,D. module generally handles 16 lines, it only 
maintains active I/O on 2 of these lines at any one 
instant. It does one send/receive iteration 
simultaneously on 2 lines, then does the same on the next 
2 different lines, and so on, until it has done all 16 
lines (if selected), then it does the first pair again, 
etc. If you want to tie one line back on another line in 
the same system and both lines are being controlled by the 
same module, you must make sure these 2 lines are one of 
the "pairs" that get run together. For more on this, read 
the section on "2 Lines at a Time Considerations". 

c. Another computer system (Node). This other node can be 
another PDP-11 running DECNET DEC/X11 or it can be ANY 
type of processor by any company running any software 
(including its normal operating system) subject to 2 
restrictions. First the other end of this line must be a 



Page 10 



compatible modern and communications device and second/ the 
software must be using the ODCHP protocol (In particular, 
the Maintenance "loop back" message) or else be capable of 
accepting a message and echoing it back exactly as 
received. This other side must not send unsoiicitated 
messages to our node. So, some typical nodes which can be 
connected to our ncde would be: 

A PDP-11 running RSX-llM (if it supports DDCMP) 
A PDP-11 also running DECNET DEC/Xli 

A PDP-10 running an operating system supporting DDCMP 
A brand X computer running any software that Hill 
exactly echo messages which ye send to it. 

343.2 What Modes Can a Line Se Run In? 

A line can be run: 

a. Run or not run as selected by the bit map in location 14 
of the module. Bit on means test line 0. 

b. Master or Slave as selected by the bit map in location 16 
of the module. Eit on means, if testing line 0, treat 
it as the Master* The only difference between Master and 
Slave is which side of the line expects to transmit first 
(Master) and which side expects to receive a message 
(Slave) before it transmits. Both sides transmit, 
receive, transmit, receive, etc., over and over, but one 
line (the slave) waits to receive the first message before 
it starts the test sequence. One side of a line must be 
Master and the other Slave. It is purely arbitrary which 
side is which, as long as they are not both the same. If 
a line is connected to itself through some loop back 
device, it must be set to be Master. Likewise, if a line 
is connected to another line anywhere which is not running 
DF1CHET DEC/X11, it must also be set to Master. 

c. Half or Full Duplex. By ansyering the questions which are 
asked when the run command is typed, any line can be set 
to either, provided the hardware and the modem can do 
either, otherwise, you must set the line what the hardware 
and Modem dictate. 

d. Point-to-Point or ^ulti-Drop* Again, this is set 
according to how you answer the questions at run time. 
There is a seperate section dealing with Multi-drop. 
Point-to-Point is the normal case of 1 device connected to 
1 and only 1 other device. 

e. One way orly. If you have isolated a problem to a 
particular device, you may want to verify if the receiver 
or transmitter, or both are bad. For this reason, 
one-way-receive and one-way- transmit (G$R, QfciT) are 
provided. To use this mode, in general, all other devices 
both communication and other would be deselected, and 
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within the D.D. moule which is controlling the line in 
question, all lines but one would be deselected, (Of 
course/ N1A?/ N2A?, and the clock module roust stay 
selected to support this D.D, module.) This would be 
mainly for simplicity of operation, and other modules can 
be left running if desired/ Within the module which 
controls the line to be tested, location 176 contains an 
address (absolute, not relative to the module start as the 
176 is) which contains a 401. If the location which 176 
points to is patched from 401 to a 240 (a NOP), and the 
line being tested is set up to be half-duplex, 
point-to-point, Slave, then that line will only receive 
messages, and never attempt to transmit. It will check 
the received message for correct data* The other end of 
this line, be it another system, or another module within 
the same system, or even another line under the same 
module, should then be set to OMT. This is done by 
patching the absolute address pointed to by location 200 
of the module from a 401 to 240, selecting the line to 
half-duplex, point-to-point, and Haster. This line will 
now transmit only, never waiting to receive. Now if these 
2 lines are run, one will transmit over and over, 
regardless of what the receiving side does, while the 
receive side, will attempt to receive and check only. If 
both sides of the link run error free, the same patches 
and line specifications should be reversed, allowing 
verification of the opposite path. Some points to have in 
mind when running C«R or OWT: 

* If either locations pointed to by 176 (QWR pointer) or 
200 (Ofc'T pointer) in a module is patched from 401 to 
240/ and then the line is to be tested back in normal 
2 way mode, these locations irust be patched back to 
their original value (401). 

* ^hen a line is selected for O^T, that line is in 
effect "running free", i.e., it has to wait for 
no th ir g, and scoping can be done with no other 
considerations. However, when running OWR, this line 
will do nothing (except complain of the TIME-OUT 
errors) unless it is connected to another line which 
is doing OWT. So, it makes good sense to run a line 
Q^T all by itself, but no sense to run a line 0$P 
unless it is connected to a transmitting line. 

* If other modules are selected while trying QfcT or OWR 
on another line, it will work but the module will not 
have the complete system to itself, so it, on 
occasion, will have to wait for monitor service and 
gueing/ so scoping would be inconvenient. 

* It is legal to run one line GtfT and another OWR out of 
the fame module/ either looped to each other or to 2 
other lines. 
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* It is even legal to run 3 to 16 lines out of a module 
with some of them set for OWT and/or OWR, but the 
resulting testing mode is complicated to understand or 
interpute. This method is not recommended for any but 
the expert user of D.D. For those that want to 
atteipt this, read the following. Once the patch for 
0$T is made/ all lines selected to run within that 
D.D. module as half-duplex* point-to-point, Master, 
will be run as O'nlT. If the patch is made for OWR, all 
lines selected to run within that D*D. module as 
half-duplex, point-to-point. Slave, will run as 0#R. 
Any lines selected as multidrop or full-duplex are 
unaffected by other lines in the same module running 

f] It T r\ r HMO llalf-Hunlav, nn-int-.+ ?>-.nnir>+ 1 inoc 
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s elect e d as Slave are unaffected by patches made to 
run a OkT line, as are half-duplex, point-to-point 
lines selected as Master unaffected by patches made to 
run a OWR line. Also, with multiple lines running < 3 
or more) all lines are not running at exactly the same 
instant, while 2 are running, the others are waiting 
their turn, so scoping is difficult and care must be 
taken not to connect a line of a module to another 
line of the saire module if the 2 do not get run 
together as a pair. (See section on "2 Lines at a 
Time Considerations"*) 

3i4 Running Options 

Besides the various modes of running (Section 3.3.2) and the 
various terminations (Section 3.3.1) there are other options 
within each D.D. module. These options are made by patching 
locations within the module before running. The addresses for 
any of these option patches are standard in every D*D. type 
module. The options include: 

a. Location 164 is a switch which indicates whether or not 
ail errors should be reported as they happen. If location 
164 is non-zero (ecual to n), then receiver errors are 
totalled (on a line by line basis); (rather than being 
typed out as they happen) every n passes this total number 
of errors for the previous n passes will be reported. The 
value of n is the value of location 164. The maximum 
number of errors that can be talleyed is 256 per line. 
Therefore if a line is not known to be of very good 
quality, the value of location 164 times the value of 
location 166 should be less than 128* (location 166 is 
defined next.) This means the number of messages per pass 
times the number of passes per summary report should be 
less than 128. In this way, if every message attempted 

L ^ l_ _ _. I_ 3< J -2 - - - _ I 

iioo an ciLOL uU iii li oiiotni i aliv LcwcAVc, LiiS cnOi laiij' 

will not overflow. If the line is of known good quality, 
this restriction may be relaxed. The default value is to 
report all errors, and not give error summary reports. 

b- Location 166 indicates how many iterations per line should 
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be done before an end of pass is called* An iteration is 
normally one transmit and one receive/ in either order. 
The default value is 8. 

Location 170 is a time scaling factor. There are many 
time out loops in the modules/ some should logically be 
longer than others. The value in location 170 is the 
number of seconds to wait for the smallest time outs. 
Some time outs will be a multiple of this factor. Default 
is 30 seconds. 

Location 172 is an error toleration level/ on a single 
messace basis. So if in an attempt to do one iteration 
(usually a transmit then recieve or vice-versa) the number 
of errors reaches the value in location 172/ that line is 
dropped from testing* If before this level is reached/ an 
iteration is correctly completed/ then the error count 
which is compared to location 172 is reset to zero. The 
default is 10- 

Location 174 contains 2 identical bytes for use as sync 
characters. The default is 113226 which is 2 bytes of 
226. If this is chanced, both bytes must be identical to 
each other. This location is a don't care for 
asynchronous devices/ because they "sync" on the first 
byte of the actual message/ not on preceding characters as 
synchronous devices do. 



NOTE 

The NO A? module and the NVA? module, if both 
configured in one exerciser, reauire that the same 
sync character be used even if they are not 
connected to each other. Since the DV-11 sync 
character is set by hardware, this location must 
be patched to iratch the DV-11 hardware. If you do 
have a DV-11 and a DQ-11, then the DV and DQ's 
sync characters must both be patched to match the 
DV-11 hardware (even if they are not connected to 
each other) 



Location 176 is for One-way-receive. See Section 
3.3.2, e . 

Location 200 is for Qne-way- transmit. See Section 
3.3.2, e. 

Locations 322 through 341, the Baud Rate Byte Table, 
contain p coded bcud rate byte for each corresponding bit 
in the DVC, location 14. This table is only present for 
asychronous device modules with programabie baud rates. 
Refer to the individual module listing for what code 
corresponds to which baud rate. 
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3«f 5 Modems 

Modems, or at least modem simulators, are always required for 
synchronous communicat ions devices. Asynchronous devices do 
not for short cable distances. All CD. modules are written 
expecting modems and modem control lines connected to the 
devices being tested. For asynchronous devices/ the listing 
for individual D-D. module types may contain information on 
hoy lines can be tested without modems. The following modems 
have run D-D. modules successfully: 

Synchronous Asynchronous 
Bell 201A Sell 101A 

B , 11 *^ a /") r-t 
611 liUOC 

Com Link~~T~IT 

3^6 Multi-drop (Not ¥et Tested, so Unsupported) 

************************************ ****** 

Multi-drop is complicated and unless your 

configuration requires it, I would 

recommend not reading this section, as it 

may just add unneccessary confusion to the 

understanding of DECNST DEC/X11. 
****************************************** 

Multi-drop, or Multi-point, is a hardware configuration in 
yhich more than 2 communication devices are connected to a 
single line. In the more common mode/ point-to-point, 1 
device has its transmitter connected to 1 other device's 
receiver and that device's transmitter is connected to the 
first's receiver. In Multi-drop there is one device (called 
Master Stations) connected to 2 or more devices (called Slave 
Stations)* The slave stations can never "speak" (transmit) 
until "spoken to" by the Master. The D.D. exerciser yhich is 
running as faster will transmit one message on the line which 
is exactly like the message used in all point-to-point cases 
except the header's 6th byte (and the 7th and 3th which are 
the CPC-16 characters for the header). This 6th byte is the 
"address" byte. Every slave device on this multi-drop line 
receives this message and compares its own unique station 
address with this 6th byte. If they do not match/ the message 
is ignored. If they do match, then the slave station is 
allowed to transmit one message on the line. This message is 
exactly what it received, and since the address byte is set 
for this transmitting slave, all other slaves must ignore this 
message also. The Naster, which started this process/ will be 
expecting this "echo 11 . If it gets it ok, it will select the 
next slave station and send the message with a new unique 
address byte. If the Master does not get the echo, it will 
retry/ up to the limit specified by location 172 of the 
module. (See section 3.4/ d. ) 

When the D.D. exerciser is started, for every line selected 
to test/ the ODerator is asked if this line is Multi-drop or 
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not. If the answer Is yes, (Y<cr>) then he will be asked for 
a station address for this line if it was selected to be a 
Slave (by bit map in SRI/ location It of the module). If this 
line was selected to be Master and Multi-drop, then the 
operator yill be asked for a series of addresses, one for each 
slave on the Multi-drop line. This table of Slave's addresses 
has room for 15 Slaves. If there are less, typing a "-" 
(minus sign<cr>) will terminate the questioning for addresses. 
These addresses should be any octal number from C to 177. Any 
one module can only run 1 line as #ulti-drop Master. If you 
attempt to answer Y<cr> for a second time for a line which is 
Master, an error will be reported, and you will be asked the 
questions over. 

3*7 Errors 

There are 3 classes of errors reported by D.D. modules. 

3i7.1 Set-up Errors 

fehen specifying parameters or run time conditions, operator 
errors can be made. If detected because of incorrect or 
contradictory responses, the operator will be notified. This 
error conditions will be self explanatory. 

3*7. 2 Data Errors 

When a message is received by a D.D. module, a common 
subroutine located in the N1A? module is called to check the 
data in the message. All DECNET DEC/Xll module data compare 
errors look like the standard DEC/Xll data compare error 
message except: 

a. The module name typed is FFXX, where FF is filled in to be 
the name of the DECNET DEC/Xll module which called the 
N1A? module to do the compare. In other words FF 
represents the module that "had" the error. 

b. The error number is a count of the data compare errors in 
the current message being checked, it is therefore reset 
to zero every time a new message is to be checked. 

c. ACSR contains the address of the DECNET DEC/Xll module 
which called this routine to have its message checked; 

c. SB ADR contains the line # of the device which had the data 
error. 

e. ^ A S A D R contains the count (in octal) of which character in 
the message this bad character was* 

f. The "should be" and "was" items are normal. 



xNOTE, because the NlA? module keeps having its named 
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changed by D-D- modules doing data compares, you cannot 
expect to know yha t naiae it is using at any one time, 
'When first loaded, it is called NiXX, but it often gets 
changed while running. So do not be alarmed if in run 
summary s and maps, the name has changed to NQXXQ, NLXXQ, 
or whatever. If you want to deselect it or use the HOD 
command on it, use the name which last appeared in a run 
summary or WAP command. 

3-7.3 Running Errors 

Other running errors are reported using the normal error call 
in D5C/X 11 CSRA and ACSR are standard. STATC contains a coded 
error number, with the cods being consistent in all DECNET 
DEC/X11 modules. The low order 2 digits of STATC contain 
which line had the error the other digits contain this code: 



0010XX 


r ec 


time out 


0020XX 


tmt 


clock loss 


0030XX 


header CRC error 


0040XX 


msq 


CRC error 


0050XX 


tmt 


tiffie out 


0060XX 


tmt 


non-existent memory 


0070XX 


tmt 


latency 


0100XX 


r ec 


data parity error 


01 10 XX 


rec 


non-existent memory 


0120XX 


rec 


clock loss 


0200XX 


rec 


framing error 


0400XX 


rec 


overrun or latency error 



The first time the run time exerciser is run after loading, 
the NET 1 module will type this error code list out to the 
system console for the operators subsequent use. (Unless 
switch is up on the switch regis ter ) 

3.8 Altering the Order of Line Testing 

The module contains a table of bytes from location 212 to 231. 
Location 212 corresponds with bit of DVC (location 14 in 
module), location 213 with bit 1, etc, up to location 231 with 
bit 15. These bytes contain the line number to test in the 
lofc order 4 bits. The upper 4 bits are unimportant. Modules 
as shipped, contain a 6 in location 212, 1 in 213, 2 in 214, 
etc./ up to a 17 in location 213« This table in conjunction 
with the DVC location, tell the module which lines to run and 
in which order. The module takes DVC, starting with bit C, 
and for each b it set to a 1, runs the line number specified by 
the corresponding byte, 212 to 231. Given the default values 
in 212 to 231 and DVC set to 177777, the module would test 
line 0, then lire 1, then 2, etc* up to line 17* If for any 
reason, you would want to run the lines in any different 
order, just [codify *8yTES* 212 thru 231 to the order you want, 
making sure that every number from to 17 (octal) appears 
only once, in this byte table. For example, the default 
values of th is table look 1 ike: 
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Location 



Value 



In Bytes 



DVC 



bit 



212 
214 
216 
220 
222 
224 
226 
230 



000400 
001402 
002404 
003406 
004410 
005412 
006414 
007416 



001 
003 
005 
007 

Oil 

013 
015 
C17 



000 
002 
004 
006 
010 
012 
014 
016 



1 

3 
5 
7 

11 
13 
15 
17 




2 
4 
6 

10 
12 
14 
16 



This will test lines thru 17 in ascending order, (Provided 
the corresponding bit in DVC indicates the line is to be 
tested,) If yen wanted to test the lines in the following 
progression/ 3, 11/ 2/ 17, 1, 7, 16/ 6, 14, 0, 4, 1C, 5, 12, 
13, 15, you should modify the module to the following: 



ca tion 


Value 


In 


Bytes 


DVC 


bit 


212 


004403 


011 


003 


1 





214 


007402 


017 


002 


3 


2 


216 


003401 


007 


001 




4 


220 


003016 


006 


016 


7 


6 


222 


000014 


000 


014 


11 


10 


224 


004004 


010 


004 


13 


12 


226 


0C50C5 


C12 


0C5 


15 


14 


230 


006413 


015 


013 


17 


16 



If when you gc to modify these locations the upper 4 bits are 
non-zero, do not bother writing these bits, they are set up at 
run time, just patch the lower 4 bits to what you want. Make 
sure no two bytes contain the same line number and remember 
that no mctter fchat is done to this table, DVC, location 14, 
has the bit map of which lines will run. If a bit is not on 
in DVC, then no matter what is in the corresponding byte in 
this table/ the line will not be run. 



Due to program size constraints, D.D. modules will only 
maintain active message flows on 2 lines at any one instant. 
The program will, according to the lowest order bit which is 
on in DVC, location 14, take the first line to be tested, get 
it started, and then start the second line. These 2 lines 
will be doing simultaneous message transfers until either has 
done the required number of iterations (per location 166). 
Then that line that just finished will be dormant and the 3rd 
line (as selected by the 3rd lowest order bit in DVC) will 
become active. One of the original 2 lines may still be 
active with this 3rd line. Next this last line of the first 2 
will finish and go dormant and the 4th line will be started. 
It will be running simultaneously with the 3rd line* This 
process repeats until the last line selected is complete. 



3*9 



2 Lines at a Time Considerations 
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Then an End-of-Pass call is made and the whole process starts 
over. If all lines were running in the same test mode and at 
the same baud rate/ then lines and 1 would run and finish, 
lines 2 and 3 would then run, etc- up the line 16 and 17 
(octal). If however/ line was running 20 tiroes slower than 
the other 15 lines (say because of different baud rates) then 
line would start/ and each line 1 thru 17, would be started 
and finished in turn/ , and still line would not have 
finished. $hy do you care about this? Because it is both 
possible and easy, to connect lines to lines such that a 
running line cannot finish because it must wait on another 
line which will not even get started till the first is 
finished. For example, suppose your system has 4 DL11-E*s all 
at 9600 baud and you run all 4 using 1 D.D, module- NLA?- If 
you wanted to just loop your lines on each other for a 
standalone test you have 3 choices of connections. Two of 
there will not work. If ycu connect line to line 1 and line 
2 to line 3/ it will run fine, when started/ the module will 
run line and 1 to completion, then lines 2 and 3/ and then 
do an End-of-Pass. If you instead, connect line € to line 2, 
and line 1 to line 3, it will not work. The module will start 
line and line 1, but the lines they are connected to are 
"asleep". Line will transmit over and over and get no 
response from line 2 because line 2 is not actively running, 
it will not be started till line is done! If you really 
wanted to test line C to 2 and lines 1 to 3, you have 2 
choices, either configure 2 NLA? modules and let each run 2 
lines at a time, in which case you will truly have 4 lines 
running at once, or else/ using only 1 module/ you can modify 
the order in which lines are tested (See section 3.8). By 
doing this, line and line 2 will be selected for testing 
first, and then 1 and 3. 

The same type of problems can occur between systems. Consider 
2 systems, call them A and S, each with 4 OLll-E's. If lines 
AC is connected to E2, kl to 83, A3 to EC, and A4 to Bl, the 
same type problem will happen. System A will make lines and 
1 active but they will get no action from B's line 2 and 3, 
because they won't get started until lines BO and Bl are done. 
In this case, as in most interprocessor configurations, these 
mismatched situations will usually straighten themselves out 
after a "rocky" start. Either Systei A or B would likely have 
both its lines "time out" and give up, and go on to the next 
pair of lines. These would then run smoothly, and from then 
on, System A would be in the middle of a pass while System B 
would be at the end of a pass. There would, however, be a 
long time and about 30 time out error messages (8 on each of 2 
lines on one system, and 7 on each of 2 lines on the other 
system) before the systems run. * ■ . ■ * 

So, to avoid these problems, always connect line *s to line 
0*s, l*s to l*s, etc. BETWEEN modules whether the modules are 
running both on 1 system or on 2 seperate systems. If the 
lines are looped back onto lines from the same module, connect 
adjacent (0 to 1, 2 to 3, etc.) pairs together, evenly from 
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the first line. In both cases, I mean line C to be the 1st 
line selected by the lowest order bit in DVC, the 2nd line 
would be the 2nd lowest order bit in DVC, etc.. For example, 
if you had a DVC of 010450, meaning lines 14, 10, 5 and 3 
should be tested, connect 3 to 5 and 10 to 14. 

you can connect 3/ 5 or 25 processors together in rings or 
stars or whatever pattern you like. In all cases it will be 
possible to configure D . D . exerciser to get the entire 
network to play, but care must be used not to connect lines to 
lines such that line's other end cannot get started until this 
side is done. 

liO The Future of DECNET DEC/X11 

Modules were done for the DL, Du", DQ, and the OUP devices, but 
it does not appear that other devices will be supported at 
this ti^e. Current thinking is that standard DEC/X11 testing 
along with individual line testing with ITEP will detect all 
errors. 



